In today's world, individuals rely more and more on web-based services to fulfill various professional as well as personal needs. In the course of a day, an individual may access various online services, such as email, social media, online storage, online banking and others. Similarly, in an enterprise environment, an individual may need to access various enterprise applications on the enterprise network and on the web during the workday. Often, accessing a web-based application requires the user to authenticate her session by logging-in using a login name and a password. For users working with several applications, this can require numerous logins during the course of a day.
Some applications implement “idle expiration”, which automatically logs a user out when the user does not correspond with the application for a certain period of time. Idle expiration can be inconvenient to the user if the user is required to repeat a login procedure several times a day. Also, idle expiration can result in loss of user data if the user is halfway through a task when she is logged out.
As mentioned, typically a web-based API requires a user to authenticate a session (i.e., provide the user's identity to the API) by entering an initial set of login credentials, such as a password and a login name. In exchange for the login credentials, the API then sends a session key, which may be a random alphanumeric sequence held by a client application on the user's device, such as a web browser. The server hosting the application remembers the random sequence and associates it with the user identity.
Subsequently, the client application supplies the session key with every call made to the API to authenticate the user. The server matches the received session key against all kept session keys and obtains the user data corresponding to the received session key.
Upon completion of the interaction (e.g., when the user elects to log-out), the client application asks the server to log out of the session. The server then removes the session key and associated user identity from its memory, thus preventing any further calls with that session ID.
In addition, many server implementations implement expiration for the session keys where the validity of a session key is terminated after a certain period of time. Some servers implement idle expiration, as mentioned above, where when a given session key is not used for a certain period of time, the server automatically terminates its validity. This type of expiration is implemented to minimize the risks of attackers stealing session keys and performing operations on behalf of the original user. Some servers implement a maximum session lifespan, where a session key is set to expire a fixed interval of time after login. This type of expiration is set to reduce the risk of attackers guessing the session key of long-running user sessions.
When a user is involved with multiple applications, she may need to perform the login procedures for each application and be additionally burdened with expiration constraints.
Numerous efforts have been made to simplify the experience of authenticating multiple services. The public standards to date focus on having end users authenticate manually at a single application that then creates tokens to be used for secondary authentication with various other applications. Examples of this include SAML, OAuth, OAuth2, and OpenID standards. With these standards, credentials are created by an initial application that verifies the end user identity and the credentials are then used to generate session keys for each accessed server hosting other applications. Thus, the problem of maintaining multiple session keys and respecting multiple session key expiration policies is not solved.
Other solutions provide single session keys that are used across multiple applications. However, those solutions typically impose implementation constraints on the servers, which requires substantial modifications. One such approach, popular with software as a service (SaaS) companies, is a shared session manager. In this scenario, a single repository of session keys and associated data is shared between all servers. This requires that all servers have a fast and secure connection to this common repository, is hard to scale, and is useful when the individual server applications are developed and deployed together by the same organization.
Another known approach is to encode the user identity in the session key. In this approach, the user identity is encoded in the session key itself and is protected cryptographically against forgery. Upon receipt of such a token, the server implementation checks the integrity of the token using cryptographic techniques and obtains the user data from the session key, which is further used by the implementation. An example of such a standard is JWT (JSON Web Token). While this approach has some advantages, it requires server-side modifications to implement JWT, which is not always feasible.
A more efficient approach is desirable for providing a single session experience across multiple applications that cannot share common session management, which does not require the user to log into each application separately and takes into account expiration policies of the multiple applications.